Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found some lint.

Here's what I've got...

For recipe/meta.yaml:

• ❌ You're setting a constraint on the __osx virtual package directly; this should now be done by adding a build dependence on {{ stdlib("c") }}, and overriding c_stdlib_version in recipe/conda_build_config.yaml for the respective platform as necessary. For further details, please see META: {{ stdlib("c") }} migration conda-forge.github.io#2102.

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/19622705669. Examine the logs at this URL for more detail.}

Please increment blas_minor for 3.12 by 100

Done locally. I'm working on BLIS bump first, then I'll push to see if that improved anything.

Done locally. I'm working on BLIS bump first, then I'll push to see if that improved anything.

Could you rebase this PR on main, even without the blis stuff?

Done.

Not looking too good for 3.12 for now; we'll definitely need a blis update, but also MKL does not look compatible yet (missing symbols and thus failed tests)

For expectation management, I had been trying to update our lapack stack past 3.9.0 since almost 5 years ago, so don't be surprised if this takes a while. Before running into the MKL SDL failures, the longest wait was for MKL to become compatible at all -- I recommend asking for an update in conda-forge/intel_repack-feedstock#26

Am I also seeing correctly that Accelerate is quite incompatible too? I guess that's going to be a hard blocker, unless we want to proceed with the alternate approach of per-platform LAPACK versions.

newaccelerate should be compatible with 3.12 (as of macOS 15.5, c.f #158), but it's possible that that's only for 3.12.0 and not 3.12.1

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.
• ℹ️ libcblas output overrides versions pinned in the feedstock:
  ['- In section host: libblas 3.12.1 0*_openblas']
  Requirement spec should not list version specifiers to respect conda-forge-pinning. If you need to force another version, please override the pin via conda_build_config.yaml.
• ℹ️ blas-devel output overrides versions pinned in the feedstock:
  ['- In section host: openblas 0.3.33']
  Requirement spec should not list version specifiers to respect conda-forge-pinning. If you need to force another version, please override the pin via conda_build_config.yaml.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/26493188258. Examine the logs at this URL for more detail.}

Ok, I think the problem with BLIS is that liblapack.so from Netlib is now LP64+ILP64 library, and therefore requires LP64+ILP64 libblas.so. I think this will be causing cross-package compatibility issues in general, so we need to rebuild it without the ext API.

@h-vetinari, looks like it's pulling liblapack-3.12.1-5_h276a3f0_netlib even though it seems to be marked broken. Any clue what's wrong here? Should we rebuild with lapack-feedstock with build number 6 to work around this?

looks like it's pulling liblapack-3.12.1-5_h276a3f0_netlib even though it seems to be marked broken. Any clue what's wrong here?

I can only guess that something is going wrong with the fact that those builds were marked broken on a non-main label; I've removed the lapack_rc label now (so now the builds are just under broken), which should keep them from being pulled in. Perhaps give it a bit of time for the channel to be re-indexed.

Hmm, still something suspicious:

/home/conda/feedstock_root/build_artifacts/blas-split_1764948318319/work/build/bin/xexample_DGESV_rowmajor: symbol lookup error: /home/conda/feedstock_root/build_artifacts/blas-split_1764948318319/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_/lib/liblapacke.so.3: undefined symbol: zggev3_64_

@h-vetinari, could you also remove the label from liblapacke?

@h-vetinari, could you also remove the label from liblapacke?

now removed from all the associated outputs of that build. Not sure why that didn't occur to me yesterday, sorry

Ok, BLIS looks good now.

What remains:

• missing cgemmtr_ in mkl
• missing cgemmtr_ in (old) accelerate
• Windows/OpenBLAS:

  ** On entry to CGEMM  parameter number  1 had an illegal value
  […]
  fatal Fortran runtime error(D:\bld\blas-split_1765005415426\work\BLAS\TESTING\zblat3.f:3973): Data edit descriptor 'I' may not be used with a REAL data item
  

Looks like cgemmtr_ is now present in MKL 2026 / openblas 0.3.33, but we still have

96% tests passed, 4 tests failed out of 96

Total Test time (real) =  50.83 sec

The following tests FAILED:
	 84 - BLAS-xblat3s (Failed)
	 87 - BLAS-xblat3d (Failed)
	 89 - BLAS-xblat3c (Failed)
	 92 - BLAS-xblat3z (Failed)

			-->   LAPACK TESTING SUMMARY  <--
		Processing LAPACK Testing output found in the TESTING directory
SUMMARY             	nb test run 	numerical error   	other error  
================   	===========	=================	================  
REAL             	271576		1	(0.000%)	1450	(0.534%)	
DOUBLE PRECISION	279072		3	(0.001%)	1461	(0.524%)	
COMPLEX          	44121		0	(0.000%)	857	(1.942%)	
COMPLEX16         	260190		2	(0.001%)	1378	(0.530%)	

--> ALL PRECISIONS	854959		6	(0.001%)	5146	(0.602%)

on win+MKL, resp

98% tests passed, 2 tests failed out of 111

Total Test time (real) = 179.75 sec

The following tests FAILED:
	104 - BLAS-xblat3c (Failed)
	107 - BLAS-xblat3z (Failed)

for win+openblas; the old accelerate will not be recoverable, but that's fine and can IMO be dropped.